That's a mouthful. We had a customer asking for information on this, so I did a couple screen captures using byzanz to demonstrate. The first shows howto setup a system to do bios over serial. I did this w/ the remote java console, but you can also do this locally on the system (or the ActiveX console I suppose, but I've never tried this myself). In brief, you need to choose a serial port to map to the VSP (I use COM2 aka ttyS1), and tell the system to redirect the BIOS to the same serial port at your desired baud (115200 in this example). The second shows me initiating an ssh session, setting up a virtual cd-rom, and booting the debian installer. Of course you could use local media or even PXE boot. But either way you need to tell the installer to direct its console to the same port that you've configured as the VSP and at the same baudrate (console=ttyS1,115200n8 in this example). Note that if the screen goes blank after attempting to boot from the CD it is likely that the installer is displaying a graphical splash screen. Simply hit F1 to transitition to a text-mode help screen.

We're trying to mitigate the severity of #404927 by working around the issue in udev. But, to do that, we need someone to provide us with udevinfo output for these controllers. If you have access to one, please help!

Lucas, try bip. It's not nearly as buggy as ctrlproxy, and allows multiple client connections, unlike dircproxy.

As announced in August, HP has now gone live with support for ProLiant. More information is available at http://hp.com/go/debian. Admittedly its odd to announce sarge support right before etch releases, but hey - we had to start somewhere. On a similar topic, I started a wiki a while ago to track the status of sarge and etch on various ProLiant models. I think it'd be cool to have similar pages for various vendors. By linking to d-i installation reports, I hope this will reduce duplicate information.

Good idea Tollef. Here's an xchat port.

hpodder is awesome, thanks John!

After doing the last 4 rounds mostly by hand, I've started automating a lot of the process with a make system. Essentially, make will find an appropriate machine, use pbuilder to perform the build, then bring all the results back locally. Considering I've had to restart builds 3 times this round, the extra time spent automating it has already made up for itself. Of course, I already see a number of places that need refactoring... I need help testing! Please checkout the wiki for details.

Since the sarge1 updates went out, Moritz, Horms & I (with help from others) have compiled a large set of issues (some very old ) that potentially affect woody/sarge/sid. We've made a few passes through them, and are now at a point where we could use some help resolving the last handful. Once we're done with that, I plan to start posting test builds on kernel.debian.net & tracking status on the wiki Woody builds still need some testing as well, if we're ever to get those out.

A while back I wrote an svn post-commit hook for the kernel repository that will look for new bug closures in the changelog, and mark them pending in the bts. Originally I'd rolled my own code to do the bts interaction, but someone pointed me to the bts command in the devscripts package, so it uses that now. The script is at svn.debian.org:~dannf/bts-mark-pending, if anyone else wants to use it.

Troy Heber and I have been setting up a multi-architecture Debian build cluster - basically a bunch of machines we can build/test kernels on. We got our hands on a Sun Blade 1000 a while back, and I had a good excuse to try and install it today. Troy said he'd tried one of the d-i nightlies, but had problems with it, so I decided to try sarge. I burned a sarge CD (which is 2.4 only, surprisingly), but it hangs after printing "Remapping the kernel...". Unlike other instances google finds, it never prints "done". I found that the net boot flavor has a 2.6 kernel - I tried it, but I get an oops as soon as it tries to load the scsi driver (sym53c8xx_2). It leaves modprobe hung in the D state, and all further modprobes hang behind it. Hoping that the cdrom boot method was to blame, I tried netbooting the 2.4 kernel flavor. This went smoothly, at first. But immediately after configuring the network w/ dhcp, the keyboard goes to hell. Only the left ctrl key seems to work (which I discovered using the tried and true bang-all-keys method), and it behaves like an escape. I tried a non-sun USB keyboard, but it had the same problem. I dug up an old non-USB sparc keyboard, but the box won't boot w/o a USB keyboard connected and d-i won't respond to the non-USB one anyway. I guess I could try running d-i with the text frontend, or maybe preseeding the whole thing... I remember some keyboard remapping on my sparc32 box that occurred when I moved to a 2.6 kernel - I wonder if something in userspace is attempting to compenate for that change? But that wouldn't explain why it only happens post-dhcp. Also.. I wonder why d-i is all monochrome on this box? Kind of annoying to navigate the menus when I can't see which option is highlighted. Unfortunately, this box has no serial port - I'll have to try to dig up one of the four port serial pci cards we once had lying around & try to setup serial console, which is what we'll want eventually anyway. Another option, I suppose, is to try installing woody then upgrading to sarge..

On various proliants, you can make it all the way through the install until the bootloader install. I'd noticed this before and had assumed it was a bug in grub. Turns out this is also a problem with lilo. I didn't pay much attention to it at the time because I could use the etch installer to install sarge and things worked fine. But, last week I had a reason to look deeper - turns out the problem is due to an outdated cciss driver. Replacing just the cciss.ko module with one backported from 2.6.12 makes the problem go away. That, and the fact that the 2.6.12 cciss driver added support for a number of new SmartArray cards, are a couple reasons I'd like to get this backport added to the Debian kernel in a point release. In the meantime, if someone needs an installer w/ a patched kernel, please contact me. Though, hopefully a sarge install with the etch installer will work fine.

I've not had much experience with git, but one feature I'm really liking is git-bisect. I often run into cases where a bug exists in one kernel but was fixed in another, and I need to pin the difference down to a single changeset. As an example, I recently discovered that an issue I'm working on in 2.6.8 no longer exists in 2.6.12. So, I went through the manual bisect to narrow the fix down to a changeset between 2.6.10-rc3 & 2.6.10. But that could be any of hundreds of changesets :( I decided it was a good opportunity to try git-bisect. It adjusts my tree to some intermediate state, I build and test. I tell git whether the results of my test were "good" or "bad", and it adjusts my tree once again. Very cool. The only annoying thing about this example is that I had to reverse the meanings of good & bad, because git bisect assumes that you're looking for the patch that fixes a build, not the one that broke it.

I recently blogged about how fixing d-i on cciss was just a matter of backporting a new version of the driver. Well, I was full of shit. Turns out my test case will give a false positive sometimes - oops. Anyway, the real fix requires backporting two fixes. Hopefully we can get this fix into a sarge point release at some point. On that note, I've started usertagging bugs that I think should go into a sarge kernel point release, should we ever do one (Note: the kernel team/stable release manager haven't discussed what is/is not acceptable in a stable kernel update, so this is just a wishlist at this point.) In my opinion, any localized fix that has already gone upstream and can be easily tested should be permitted. I'd really like to put driver updates in that category, but that opinion maybe tainted by my day job. We maintain a branch of the sarge d-i stack that has a side-goal of adding support for new HP hardware. We keep it as close to sarge as possible (backporting drivers to 2.6.8, for example) with the hope of pushing as much as possible into a sarge point release. Thanks to Andrew Patterson it has pretty recent cciss & fusion drivers. If there is interest, I could probably start posting these somewhere public.

I ran into a guy I knew from high school when I was back home - he told me about his band Liquid Cheese and that they were trying to book a show in Fort Collins. Last week I noticed a poster for their show outside of a small venue in town (SurfSide 7), so I showed up to check it out. The opening band was Thank You Donnie from Denver - a pop/punk 4-piece that were actually pretty good. Thank You Donnie finished their set around 11 & packed up their instruments. We waited 10 minutes.. 30 minutes... after a while, one of the bar employees took down the backdrop behind the stage. wtf? I went outside to call the guy I know from the band, and he says their booking agent forgot to e-mail them back to tell them they got the show - they were in Denver where they'd be playing the next night. Shit... well, sorry Shawn - I'll catch you guys next time. The cover was only $2, and it was an excuse to drink beer on a Tuesday night, so it wasn't all bad - plus I stole one of their posters.

I recently found out what these new-fangled podcast things are all about. I was playing with Rhythmbox the other day and noticed it had a built-in podcast feature, and I'd recently noticed that my favorite radio station is now doing podcasts, so I decided to investigate. After a few days of that, I decided that I approved of the concept. I bought a Neuros a year or two ago, and I spend about an hour or so bike commuting with it every day. Adding music to it is slow (USB 1.1), so I normally end up listening to the same music for a week or so. What I really want is to just plug it in at night & have fresh music on there ready to go the next day. But I also want to keep the flash full, so I don't want it to flush the old stuff unless it needs to - so I wanted something kinda like a FIFO. First thing I needed was something to track podcasts for me; rhythmbox is nice, but I need something scriptable. For now I'm using podracer. Its not very configurable, but it does the trick. I prototyped this all in shell using the positron command line interface, but then immediately rewrote it in python using the positron libraries instead. I then added a wrapper for cron to run that makes sure podcasts are up to date, the neuros is mounted (very easy now that udev automatically creates device files that are unique to a device under /dev/disk/by-id/), etc. It should be trivial to split the audio-device specific code into modules - which I'll need to do as soon as I find a physically smaller, logically larger flash player that works well with linux (I was looking at the iRiver T20, but have only read bad things about linux compatability).

I've been working on generating complete USB stick d-i installs - (with all necessary packages, not just base) on the stick. The way I ended up doing it is by starting with the d-i manual's instructions for booting from a usb stick w/ an embedded netinst ISO image. I did all this on the first 128MB partition of a 2G stick, then created an ext2 filesystem for a second partition containing an archive of all the packages I wanted available in the second stage (sarge-based d-i, so still has a second stage). I had problems getting the stick to boot from the first partition - the install-mbr tool didn't do the trick for me. Instead, I cat'd the mbr.bin file from the syslinux source package (not currently included in the syslinux binary package) onto the raw block device. Its also important to make sure your syslinux-configured partition has the bootable flag set (parted /dev/uba -- set 1 boot on) - syslinux doesn't appear to chain to partitions that don't. It might be better to combine the netinst ISO and the full archive into a single archive embedded in an ISO so that no manual mounting/apt configuration is necessary. But it'd also be cool if the ISO scanning in the second stage was capable of scanning local partitions for archives as well.

Upstream released 2.6.16 yesterday, and thanks to the non-me members of the kernel team/ftp-master teams, packages are making their way into sid. I tried to get ia64 working before the upload, but got sidetracked debugging an issue that turned out to just be out-dated firmware on my box and didn't get the new configs tested in time. Anyway, I cleaned up the ia64 configs today, and took care of hppa while I was at it, so maybe we can try a 2.6.16-2 tomorrow.

I switched to evolution from mutt a little over a year ago. I found that I really need a side-panel list of folders and some better calendar integration. Since then, I'd discovered muttng and other ways of dealing w/ calendar stuff at work, but I just couldn't make myself go through the MUA switch again. Today I have a couple new . (No offence intended to the gnome/evo guys - they've been responding quickly, and ia64 doesn't have a huge desktop userbase - its something I've wanted to do for a while anyway). I spent a couple hours splitting out configs so that I can share all of my common settings across machines, and have customizations where necessary for specific locations/situations. I used the 'source file ' syntax to call a shell script that uses heuristics to guess at my environment & generate relevant pieces of muttrc. I'm already (re-)impressed by how much quicker I can process mail, and of course, the fact that I can customize every little property of the MUA. And I can use my $EDITOR again :) Now I guess I should take another look at calendaring tools to go with it - I hear sunbird has pretty good support for read/writing calendar info via WebDAV...

I'm currently sitting in Denver International awaiting a flight to Houston where I'll meet up with Taggart for the flight into Mexico. There we'll meet up with some other folks (Ryan Murray, Troy Heber & Junichi Uekawa at least) and take a cab down to Oaxtepec. We've had *tremendous* trouble booking our hotel room (and by we, I mean Troy). In fact, last we heard they were cancelling our reservation. I strongly suspect this is an attempt at bribe soliciation, or maybe they actually just don't want to do business with us? Not quite sure - my employer is sponsoring my travel here, and I haven't noticed a "bribe" category on the expense report.. maybe I can list it under tip? :) Oh well, I suspect the worst case is that we can find asylum for a night on someone's floor until our accomodations get worked out. I'm very much looking forward to arriving at DebConf & seeing everyone, not to mention trying the local cuisine :)

The next kernel update for sarge is being prepared; testing is welcome - please note your status on the wiki. Also, for those job seeking types, HP has some jobs open in the Open Source and Linux Organization. You can search for them here.